A multi-party conference service (MPCS) is a media flow service which provides audio and video for a multi-party conference group composed of plural members. Each user who is member (hereinafter, referred to as “member user”) can not only receive the media flow but also send the media flow to the multi-party conference group.
However, in the usual situation, the media flow of content received by each member of the multi-party conference service group is almost identical. Therefore, in the MPCS, peer-to-peer transmission, multicast transmission or concentrated unicast transmission can be used to send the media flow. Plural drafts were submitted by a Session Initiation Proposal Investigation (SIPPING) working group organized by an Internet Engineering Task Force (IETF), and the frame and session control of the MPCS were defined based on a Session Initiation Protocol (SIP). Among these, a third party session control proposal which was submitted, was intended to suit a densely interconnected MPCS system.
FIG. 1 is a topological diagram of the network of a multi-party conferencing system submitted by the SIPPING working group organized by with IETF.
The multi-party conferencing system based on SIP comprises a conference focus 4, member user 1, media server 3 and SIP server 2 as shown in FIG. 1, and since signaling (shown by a dotted line 101 in the diagram) relations between all the member users 1 in the conference group are maintained by a conference focus signal unit of the SIP conference service, the conference focus 4 is formed in the star-shaped network topology shown in FIG. 1.
The main task in the conference focus 4 is to guarantee to effectively send the media flow concerning the conference to the member users 1.
For this, the support of one or more of the media servers 3 is required. The role of the media server 3 is to receive one or more media flows, and after processing them, send the one or more media flows.
The solid arrow 103 and dotted arrow 102 in FIG. 1 respectively show the down-link and up-link, respectively. The conference focus 4 is effectively disposed relative to the media server 3 by adjusting the media policy.
Each conference service has its own conference group policy and media policy, and all these policies can be accessed by the conference focus 4.
In general, the conference group policy can be understood as a context of the session which describes by what method the conference service should be offered.
One of the tasks of the conference focus is how to execute these policies. When a change occurs to these policies, the conference focus must be informed thereof. These changes touch off some sort of SIP signaling (e.g., a certain user who is refused by sending a leaving message (BYE)). The member users should be informed of all of these changes via a conference notification service.
The XCON (Centralized Conferencing) working group of IETF defines the contents which relate to the conference group policy and the media policy. In the conference service, it is uniquely indicated by the Uniform Resource Identifiers (URI) of the SIP, and the URI uniquely indicates the conference focus related thereto. For example, the URI of the conference service is set to SIP:CONF_ID@conference.com, and this indicator is the SIP URI of the conference focus.
Some proposals have been submitted to solve the problems associated with the group control policy and media control policy of the multi-party conference service also in the XCON working group of IETF. MPCS can be widely implemented on operators' networks, and supports many applications such as, e.g., video conference, distribution type video games and forwarding of local information because of easy application expansion.
In the MPCS service group, since the member user's received media flow is almost identical in most situations, in theory, the resource utilization in the mobile network can be decreased by using the layer 3 IP multicast. However, the related wireless connection network cannot support a layer 3 IP multicast when some member users are using mobile terminals (e.g., the mobile terminal CDMA 2000) to connect to the MPCS service group. Therefore, the media flow can be sent to these users only by using the unicast method shown in FIG. 1. When the number of users who use mobile terminals increases, such a method leads to serious wastage of resources.
In such a situation, an ideal method of resolving this problem is to implement transmission of the media flow related to MPCS by using broadcast/multicast service technology which can provide a service for plural mobile terminals using one wireless resource. The superior point of such a method is that it can be optimized for resource utilization of a wireless communications system related to MPCS.
There are various frameworks for the broadcast/multicast service in a conventional wireless communication network, but here, the broadcast/multicast service system configuration will be described taking only the example of the broadcast/multicast service (BCMCS) of the CDMA 2000 system.
FIG. 2 is a distribution simplified view of a function node of the BCMCS system.
As shown in FIG. 2, a BCMCS controller 8 manages information related to the BCMCS session by a core network apparatus, and related information is provided for each Packet Data Serving Node (PDSN), Broadcast Serving Node (BSN), BCMCS mobile terminal 5 and BCMCS content server 7. The BCMCS controller 8 sends information related to the BCMCS session to the Packet Data Serving Node and the Broadcast Serving Node via an interface 202. After authorization of service is received, the cost is calculated for this information (executed by the AAA unit of FIG. 2).
An interface 203 in FIG. 2 provides information related to the current BCMCS session for the BCMCS mobile terminal 5. This interface is referred to also as BCMCS information acquisition, and it performs authorization of the BCMCS mobile terminal 5, authorization confirmation and integrity protection, and prepares to send the BCMCS session of the BCMCS mobile terminal 5. The interface between the BCMCS controller 8 and a BCMCS content provider 6 is not defined in 3GPP2.
The media flow of the BCMCS session was sent from the BCMCS content provider 6. The BCMCS content provider 6 may be installed in a mobile communication operators' network, or it may be provided by a third party. After receiving the media flow sent from plural BCMCS content provider 6 via an interface 204 of FIG. 2, the BCMCS content server 7 performs various processing on the media flow under the control of the BCMCS controller 8. Next, the BCMCS content server 7 forwards the BCMCS media flow generated via a multicast router (MR) and Broadcast Serving Node (BSN) to the CDMA 2000 wireless connection network. Both the Packet Control Functional units (PCF) and Access network (AN) apparatus generate extra IP multicast packets, and can send them one after another.
The BCMCS controller 8 also has some security functions, e.g., it has the function of generating a security key and sending it to the BCMCS mobile terminal 5. The BCMCS controller 8 is also responsible for authorization control of the BCMCS content provider 6 and forwarding of the media flow to the BCMCS content server 7 of the BCMCS content provider 6.
It is ideal if the member user of the multi-party conference service is a mobile terminal (e.g., CDMA 2000 mobile terminal), the media flow can be received by using broadcast/multicast service technology (BCMCS technology shown in FIG. 2), and the broadcast/multicast service technology is combined with MPCS, which solves the resource utilization problem. However, only the service frame and the service policy are defined in the method related to MPCS proposed by IETF, and it has nothing to do with prospective solutions for different member user features. In order to combine the broadcast/multicast service technology with MPCS, there is first the problem that the BCMCS controller controls an associated BCMCS session via the MPCS service, and the status of the connection network is also different from that of other member users. Therefore, the problem of how to combine broadcast/multicast service technology with the MPCS service in a seamless manner was still unresolved.
In the prior art, there are some patent applications concerning a multi-party conference service based on SIP. For example, some of the proposed solutions are used to control a group communication session, and the majority relate to mobile networks (US Patent applications US2004/0057449A1, US2003/0012149A1 and US2002/0102999A1). However, the purpose of these patent applications is mainly to improve the function of a PTT (Push-To-Talk) system, and none of them relate to a broadcast/multicast service.
In addition, some patent applications propose solutions for resolving the group communication session of different connection network member users, but they still do not relate to BCMCS (US Patent applications US2004/0125802A1 and US2004/0125760). In short, some of the current patent applications related to MPCS do not deal with broadcast multicast service content.
Therefore, since the problem of using broadcast/multicast service technology in MPCS was not yet resolved, it was impossible to use broadcast/multicast service technology in a seamless way in MPCS.